Support for local clients to directly send graphics rendering requests to the graphics hardware without interacting with the window system proper is a technique known as direct graphics hardware access (DGHA). DGHA mitigates both context switching and protocol packing and unpacking overhead for the execution of rendering requests to windows; such rendering requests can be executed directly by DGHA clients. While DGHA helps the performance of window rendering requests, non-rendering requests such as CreateWindow and AllocColor continue to be executed by the X server. Whether pixmap rendering requests use DGHA techniques depends on the DGHA implementation, though most implementations probably do not support direct pixmap rendering.
Many workstation vendors implement some form of DGHA, particularly to support 3D rendering when graphics hardware might otherwise be under utilized. The techniques used vary from software locking of graphics for multiple rendering processes [5] to utilizing asynchronously context-switchable graphics hardware [26,15,17] that virtualizes graphics rendering [27].
Two major impediments to implementing DGHA for X are the global nature of X resources and the semantic restrictions of atomicity and sequentiality demanded by the X protocol.
The global nature of X resources greatly complicates DGHA for X rendering because X resources such as graphics contexts and pixmaps are allocated from a global name space accessible to all connections to the X server. Potentially, an X client can access the resources of any other client (in practice this is rare). This means DGHA implementations are violating the strict sense of the X protocol if they handle the state of X resources such as graphics contexts and pixmaps as local to their usage.
OpenGL's GLX extension for X [13] explicitly supports a form a DGHA known as direct rendering (as opposed to indirect OpenGL rendering that is executed by the X server). GLX provides this functionality by explicitly distinguishing direct resources that can be maintained within the client from indirect resources that are maintained globally within the X server.
This solution is unfeasible for X DGHA implementations because it is impossible to redefine the existing global nature of X resources.
X atomicity demands that ``the overall effect must be as if individual requests
are executed to completion in some serial order.''
X sequentiality demands that ``requests from
a given connection must be executed in delivery order.''
Strictly interpreted, the atomicity requirement would make virtual graphics techniques employing asynchronous context switches illegal because atomicity could not be guaranteed. The expense of the atomicity requirement for rendering operations is unfortunate since few tangible benefits derive from it.
It is entirely expected for X protocol requests within a connection to execute in their generated order. But this sequentiality requirement forces extra synchronization when rendering requests are executed separately from the non-rendering requests. Effectively, DGHA means rendering and non-rendering requests are executed in two distinct streams
For example, a MapWindow non-rendering request could be generated to map an override-redirect pop-up menu, followed immediately by rendering requests to draw the menu. The X client must guarantee completion of the MapWindow request before using DGHA to execute the rendering requests or else the rendering will likely be done to an unmapped window. This implies an X11 protocol round trip must be performed after the MapWindow. The reverse guarantee (that non-rendering requests must not execute before rendering requests) must also be made, but it is easier for a client to know a DGHA rendering request has completed.
OpenGL's GLX explicitly distinguishes the OpenGL rendering stream from the X protocol stream, in effect relaxing X protocol semantics for OpenGL rendering. The glXWaitX and glXWaitGL routines allow a user to explicitly synchronize the streams.
For OpenGL, this explicit solution for supporting DGHA is reasonable, but for core X rendering the solution is unworkable because X programs implicitly rely on non-rendering and rendering requests executing sequentially as expected.
Table 2: X protocol request ratios for various X client protocol traces. A render
request is a core protocol request potentially appropriate for DGHA use; that
is, it manipulates graphics contexts or reads or writes pixels excepting ClearArea.
Contrasting D11 to DGHA approaches, D11 requires no semantic changes to the X11 model (though relaxing the atomicity requirement for rendering is probably useful) and, unlike DGHA, D11 does not segregate the execution of rendering requests from non-rendering requests so no extra synchronization is needed between the two requests types. DGHA helps only DGHA-capable rendering requests while D11 helps all classes of requests. Table 2 shows that X clients combine rendering and non-rendering requests, particularly during program startup. The results show that for many clients, more than 40% of the requests are non-rendering requests that DGHA will not improve. It also indicates the likely cost associated with synchronizing DGHA requests with non-DGHA requests. The ratio of replies to requests indicates that up to 25% of requests require replies, generally each necessitating a client/server round trip, an expensive operation that gets no benefit from DGHA. The percentage of rendering requests is overstated because it also includes pixmap rendering and CopyArea that many DGHA implementations will likely not improve.